You Might Not Need Redux

#状態管理 #Redux #You_(might_|_do)_not_need

Dan AbramovのReduxについての記事

https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367

useEffectと同様に思想を理解していない人たちにReduxが乱用されている事実に対しての意見表明

Reduxが含んでいるトレードオフは、「how things change（どのように物事が変更するか）」から「what happened（何が起きたか）」を分離するために間接参照を追加すること

Redux#6417b82286603000002c1339

stateful componentに対してこれを行うべきですか？あなたがこの追加された間接参照から利益を得るプランを持っていない限りは、おそらくnoです。プランを持っていることは、我々の時代の用語で言う🔑となります。

しかし、もしあなたが何かをトレードオフするのであれば、必ず見返りに何かを得るようにしてください。

@mizchi: redux 要不要の議論は未だに悩ましく標準機能で redux 相当のことはできるが細かいチューニングが難しく、主に redux でSSR でデータ渡ししてた古のSSRは next に置き換えられたり、swr とか周辺ツールで非同期処理を関連は吸収されていったが、結局複雑なローカルステート処理はreduxがまだ優秀

@mizchi: useSelector 相当のものがなぜ難しいか、redux はアプリケーション全体を一つのJSONで抽象するという思想のライブラリで、そのため内部にクソデカJSONが発生するのだが、クソデカJSONから値を切り出して再分配するときにセレクタ関数の結果の同一性をチェックしてレンダリングを抑制する。ここが難しい

@mizchi: その辺を redux 以外でやってるのが https://t.co/muvP0DQnhF さんの react-tracked とか jotai とかその辺になって、ベストプラクティス積み重ねた redux-toolkit vs 軽量 alternative の jotai や recoil みたいな世界観があったのが1年半前ぐらいで、そこからしばらく React 書いてない

koushisa.icon

useEffectと同じノリを感じる

React Docs > Escape Hatches

正しく使う方法よりも複雑なデータフローを避ける方法を知っているほうが重要という